The invention originated in response to the need for reliable audible alarms in critical monitoring environments, such as medical patient monitoring. The monitoring systems deployed in these environments are often based on a system architecture that combines sensing hardware, a processor running a software program with logic for detecting alarm conditions, and hardware for generating audible alarms signals.
In the medical patient monitoring setting, monitoring devices typically use a combination of audible and visual signals to warn clinical caregivers of a condition that requires their attention. A typical instance would be when a measured physiological parameter (such as heart rate) has exceeded or fallen below preset limits. Although this type of system has a degree of built-in redundancy by providing both visual and audible alarms, the audible alarms are most important because the clinicians do not usually focus their attention on the visual display, but are instead preoccupied with a wide range of other tasks. Thus, the failure of an audible alarm might be reasonably expected to lead to the failure of a clinician to notice a condition that should have required attention. In the medical patient monitoring setting, the consequences of failing to notice and respond to such a condition in a timely manner can be serious, including patient injuries or even deaths. Consequently, the reliability of the audible alarm aspect of critical monitoring systems is of major importance.
Most patient monitoring devices incorporate a single speaker for audible alarms. This design has the obvious weakness that if the speaker fails, the audible alarm function will be lost.
In recognition of the potential seriousness of audible alarm failures, manufacturers have taken a variety of approaches. One approach is to treat the speaker as a “critical component”, giving it special treatment in the risk analysis, purchasing, manufacturing, and testing processes. While this approach gives due recognition to the importance of having a good quality speaker, it cannot completely eliminate the possibility of speaker failure.
Focusing on the speaker alone does not address the potential for audible alarms to fail due to defects in the signal path to the speaker (such as loose wires or broken traces on a printed circuit board). One way to protect against this is by providing more than one path between the processor chip and the speaker. While this is an improvement, it does not address the potential failure that might occur due to a defect right at the processor chip connection (such as a manufacturing flaw), or the potential failure of the processor chip itself. Even more problematic is the potential for software hang-ups that would keep the processor from generating the signal for an audible alarm in the first place.
Another approach is to provide two independent signal paths from the processor to two independent speakers. This design effectively protects against the possibility of a failure in one of the speakers or one of the signal paths, provided that there is some way of periodically testing both speakers to tell whether one has failed (in which case the system is degraded and reduced to the same condition as if it had only one speaker). This design is still unable to protect against a failure at the origin of the signal path, i.e., the processor chip, or a software hang-up.
Another approach, employed in U.S. Pat. No. 5,652,566 to Lambert (1995), is to add some form of audible feedback sensing, such as placing a microphone inside the monitor in proximity to the speaker, so that the main processor software can tell if the speaker is sounding when it is supposed to. This approach suffers from technical complexity, since it is not a simple task to differentiate appropriate speaker alarm sounds from ambient environmental sounds (which may include alarms from other nearby devices). This approach also fails to protect against hardware or software failures in the processor that is sensing the audible feedback.
Another possible approach would be to utilize two redundant, identical sets of hardware and software for monitoring the alarms. This approach has several significant drawbacks. In a typical patient monitoring device, the main processor runs a large and complex software program that handles the tasks of sampling and storing physiological data, performing signal processing to derive meaningful parameters from the data, and ultimately determining alarm conditions based on complicated rules. Most alarm conditions result from parameters going outside of preset limits. A commonly implemented alarm rule is to sound an audible alarm when a parameter has been outside of its preset limits for a preset length of time. Another commonly implemented alarm rule is to stop the audible alarm when the parameter comes back within limits, or when an operator presses a key on the monitor to silence the audible alarm. Due to the complexity of the entire monitoring task, a design in which two processors run completely independently of one another could wind up generating audible alarms in an asynchronous manner, which would be confusing and frustrating for the operators. A lack of good coordination between the two processors could lead to “race conditions” wherein the operator acknowledges an alarm condition that has been detected by one processor, and moments later the second processor detects the same alarm condition and annunciates a second alarm for the condition that was already acknowledged. Moreover, such a completely redundant design would be expensive, since it would require two equally powerful processors and all their associated circuitry.
There remains a need for reliable alarms in critical computer-based monitoring systems such as patient monitoring devices.